1. Field of the Invention
This application generally relates to message validation. Specifically, the present invention provides a message validation model (that models validation rules prevalent in EDI space but not supported by XML Schema) that converts schema level rules to message level rules.
2. Related Art
Extensible Markup Language (XML), a W3C-recommended general-purpose markup language for creating special-purpose markup languages, while becoming quite popular for a number of reasons including that it is easier for humans to read, has messages which can be quite large. The W3C XML Schema is the industry standard for validating XML document. (For more information relating to XML, see the W3C XML homepage http://www.w3.org/XML/.) While this schema is capable of validating the contents of elements based on their type, the validation functionality lacks in at least the following areas: (1) Coexistence Rules: It is not possible to specify that if a particular element exists in the instance document then a set of other elements must exist and they must have a specific set of values; (2) Multiple Element Rules: It is not possible to specify that a subset of elements defined in a complex type or group must either occur in pairs or only one of them occurs or at most one of them occurs etc.
The above rules are used very widely in the EDI domain. For background, Electronic Data Interchange (EDI) is the computer-to-computer exchange of choice for structured information, by agreed message standards, from one computer application to another by electronic means and with a minimum of human intervention. In common usage, EDI is understood to mean specific interchange methods agreed upon by national or international standards bodies for the transfer of business transaction data, with one typical application being the automated purchase of goods and services. See http://www.unece.org/trade/untdid/welcome.htm (UN/EDIFACT) and http://www.x12.org/ (ANSI ASC X12) for more information. In addition, see the above-incorporated patent applications for additional information.
In any event, in addition to the above rules, there are specific requirement from the messaging domain that are not covered in XML schema or by any related art solution: (1) Valid Values for Element Rule: XML Schema defines enumeration facet on the simple type to constrain the set of values that an element of such simple type can have. The have been instances where customer Document Type Definitions (DTDs) generated for some message sets where the set of valid values for a number of elements were in excess of 2000. The generated XSD was so large the file could not be loaded; and (2) Message Level Rules: A facility to specify Coexistence and Multiple Element rules at the message level. The key distinction between the rules defined at schema level and at message level is that the schema level rules are applicable to all instances created from schema constructs while message levels rules are specific to a particular message only. The following example illustrates the difference:
<?xml version=“1.0” encoding=“UTF-8”?><schema xmlns=“http://www.w3.org/2001/XMLSchema”  targetNamespace=“http://www.ibm.com”  xmlns schemaVal=“http://www.ibm.com”>  <complexType name=“TypeA”>    <sequence>      <element name=“elemA1” type=“string”minOccurs=“0”></element>      <element name=“elemA2” type=“string”minOccurs=“0”></element>      <element name=“elemA3” type=“string”minOccurs=“0”></element>    </sequence>  </complexType>  <complexType name=“TypeB”>    <sequence>      <element name=“elemB1” type=“string”minOccurs=“0”></element>      <element name=“elemB2” type=“string”minOccurs=“0”></element>      <element name=“elemB3” type=“schemaVal:TypeA”minOccurs=“0”></element>    </sequence>  </complexType>  <element name=“msg_globElemA” type=“schemaVal:TypeA”>  </element>  <element name=“msg_globElemB” type=“schemaVal:TypeB”>  </element></schema>
A minOccur (e.g., a minimum occurrence setting) on all elements is set to zero, so from the W3C XML schema validation point of view, msg_globElemA (e.g., message object) can be empty or contain any of the elements elemA1, elemA2, elemA3. A coexistence rule can be defined so that if elemA1 is present in the instance then elemA2 and elemA3 must be present. This rule resides on the elemA1. This is a schema level, meaning that it will be enforced on msg_globElemB as it contains elemB3 of type TypeA; so in the instance if elemB3 is present then it should either have empty contents or all the three elements elemA1, elem A2 and elemA3. If the user had intended to have this rule for the message msg_globElemA and not for msg_globElemB then it should been defined at the message level msg_globElemA. This is the main distinction in defining the rule at schema and the message level as illustrated in the above example.
In view of the foregoing, there exists a need for a solution that solves at least one of the deficiencies of the related art.